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ABSTRACT 

Applications  development  personnel  have  been  confronted 
with  the  task  of  creating  efficient  applications  to  meet  the 
needs  of  the  end-user.  Developers  have  tried  to  meet  these 
needs  by  building  their  own  individual  routine  libraries,  but 
the  wide  range  of  skill  levels  and  the  large  backlog  of 
application  requests  have  kept  developers  and  end-users 
largely  unsatisfied.  Under  the  Common  Front-End  System 
Architecture  being  installed  at  the  Marine  Corps  Central 
Design  And  Programming  Activity  Kansas  City,  Mo.  developers 
will  have  access  to  a  tool  box  of  common  functions  that  will 
help  reduce  development  time  for  all  levels  of  applications. 

A  Decision  Support  System  (DSS)  designed  to  aid 
development  personnel  in  gaining  access  to  the  data  and 
functions  necessary  for  their  development  efforts  is  desired 
by  the  Marine  Corps  to  support  Manpower  and  Pay  systems.  The 
creation  of  such  a  DSS  will  entail  gathering  data  concerning 
access  patterns  to  tool  box  functions  and  database  elements, 
definition  of  specific  tool  box  functions  to  be  utilized  by 
the  DSS,  and  definition  of  the  decision  logic  and  rule 
processing  for  use  in  determining  all  the  related  elements  of 
a  transaction. 
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I .   INTRODUCTION 

The  U.  S.  Marine  Corps'  large  scale  data  processing 
efforts  are  centered  on  three  large  databases  operating  on 
an  IBM  mainframe  computer  using  the  wide  area  network  known 
as  the  Marine  Corps  Data  Network  (MCDN) .   These  databases 
are  separated  into  three  main  functional  areas:  Manpower, 
Pay,  Fiscal;  Logistical  Support;  and  Budget  and  Finance. 
Each  of  these  functional  areas  is  under  the  control  of  a 
system  sponsor,  and  the  development  effort  within  each  is 
handled  at  a  separate  Marine  Corps  Central  Design  and 
Programming  Activity  (MCCDPA) .   These  MCCDPA's  are  subject 
to  a  high  rate  of  personnel  turnover.   Personnel  are 
constantly  moving  between  MCCDPA's  and  other  data  processing 
activities.   This  guarantees  an  influx  of  new  people  with 
changing  ideas  for  each  unit.   However  it  also  means  a 
consistent  loss  of  expertise  at  each  sight  as  personnel  who 
are  familiar  with  a  system  receive  orders  and  move  on  to 
other  installations.   In  many  cases,  the  only  expertise  or 
useful  experience  that  a  new  individual  brings  with  him/her 
when  he/she  transfers  is  that  of  the  operating  system, 
database  management  system,  other  software  languages,  and 
functions  of  the  MCDN.   The  skills  and  knowledge  from  one 
functional  area  are  rarely  applicable  to  another. 


The  database  management  system  and  fourth  generation 
language  utilized  by  the  Marine  Corps  in  the  development  and 
maintenance  of  these  systems  are  Software  AG's  ADABAS  and 
NATURAL.   Additionally,  support  of  other  procedural 
languages  such  as  COBOL  is  still  required  due  to  the  large 
base  of  existing  applications.   The  development  efforts  for 
the  new  database  systems  and  the  maintenance  requirements 
for  the  existing  applications  have  put  a  strain  on  the 
Marine  Corps*  data  processing  personnel  and  assets.   In  an 
effort  to  alleviate  some  of  this  burden,  development 
personnel  in  the  manpower  and  pay  arena  are  interested  in  a 
project  by  the  Department  of  Energy's  Idaho  National 
Engineering  Laboratory  (DOE  INEL) . 

The  DOE  INEL  has  developed  a  System  Architecture  (SA) 
for  IBM  mainframe  computers  environment  that  gives  users  at 
all  levels  a  common  view  or  feel  of  the  system  regardless  of 
the  specific  machine  type,  operating  system  or  communication 
processor  they  are  working  on.   This  SA  provides  the  user 
with  a  series  of  menus  that  contain  unique  access  choices 
based  on  each  user's  security  profile  allowing  access  to 
data  and  functions.    Access  to  other  data  elements  through 
SA  is  prevented  by  restricting  each  user's  visibility  within 
the  system  to  those  transactions  and  items  necessary  for 
him/her  to  accomplish  his/her  daily  work. 


Additionally,  personnel  are  provided  access  to  a  tool 
box  of  common  functions  that  can  significantly  reduce 
program  development  and  maintenance  time.   The  tool  box  is 
centered  on  a  logical  transaction  concept  which  is  defined 
as  the  minimum  amount  of  work  required  to  perform  some 
aspect  of  an  automated  process.   Each  transaction  or  process 
within  a  system  is  analyzed  to  determine  what  actions  are 
associated  with  it.   Once  identified,  they  are  used  to 
define  the  logical  transaction  that  is  contained  in  the  tool 
box.   After  the  logical  transaction  has  been  defined,  the 
developer  does  not  need  to  rely  on  his/her  memory  or  spend 
time  tracking  through  system  manuals  to  ensure  that  a 
transaction  he  requires  for  an  application  is  complete. 
He/she  simply  accesses  the  tool  box  for  the  transaction  and 
is  insured  of  the  completeness  of  the  transaction  based  on 
its  presence  in  the  tool  box. 

The  SA  provides  a  user  with  several  tools  to  enhance 
his/her  performance  and  productivity.   Metrics  at  the  DOE 
INEL  have  documented  38%  productivity  gains  with  the  SA. 
(Bell  R.S.  et  al,  1988) 

The  U.  S.  Marine  Corps'  Real  Time  Finance  and  Manpower 
Management  Information  System  (Real  FAMMIS)  design  team  is 
working  with  the  DOE  INEL  on  the  transfer  of  the  SA 
technology.   The  technology  transfer  will  be  accomplished  in 
three  phases.   Phase  I  is  limited  to  the  manpower  and  pay 


arena  at  the  Marine  Corps  Central  Design  and  Programming 
Activity  (MCCDPA)  Kansas  City,  Missouri  and  was  scheduled 
for  30  May  1989.   Phase  II  will  incorporate  the  SA 
technology  Marine  Corps  wide  using  the  Marine  Corps  Data 
Network  (MCDN)  under  the  title  of  Common  Front-End  System 
Architecture  (CFESA) .   Testing  of  Phase  II  is  scheduled  for 
1  October  1989.   Phase  III  is  scheduled  for  the  1st  quarter 
of  CY1990  and  is  planned  to  include  a  Decision  Support 
System  (DSS)  capability  or  tool  box  item  to  support 
development  personnel  in  the  manpower  and  pay  arena. 
Development  of  DSS ' s  for  the  other  functional  areas  are 
anticipated  to  take  place  at  a  later  date.   If  desired,  the 
functional  manager  or  responsible  MCCDPA,  using  the 
framework  established  for  the  Application  Developers  DSS  for 
the  manpower  and  pay  arena,  will  develop  their  respective 
capability. 

The  DSS  for  the  manpower  and  pay  arena  will  be  a  support 
tool  designed  to  provide  developers  with  rapid  and  timely 
access  to  the  data  and  functions  necessary  to  complete  their 
development  projects.   It  will  function  as  an  expert  system 
to  meet  developers'  needs  by  asking  the  developers  to 
specify  the  general  functions  needed  for  their  development 
project,  such  as  ADD  or  UPDATE,  and  the  primary  data 
requirements,  such  as  PAY  or  PERSONAL  data.   The  DSS  will 
use  this  initial  specification  to  access  the  tool  box  to 


retrieve  all  the  related  logical  transactions  for  the 
particular  area  of  concern.   Once  all  of  the  logical 
transactions  have  been  retrieved,  the  developer  will  be  able 
to  review,  evaluate  and  order  them  for  use  within  the 
particular  application  he/she  is  developing.   At  this  time, 
the  developer  may  choose  to  reject  entire  logical 
transactions  or  portions  thereof  if  they  are  not  necessary 
for  a  particular  project.   He/she  may  also  create 
transactions  of  his/her  own  which  meet  the  specific 
requirements  of  a  project. 

Project  development  without  the  use  of  a  tool  box  of 
common  functions  is  a  lengthy  and  painful  process.   It 
becomes  almost  unmanageable  when  it  involves  data  that  spans 
multiple  related  functional  areas  like  manpower  and  pay. 
Each  developer  is  required  to  identify  all  of  the  aspects  of 
each  transaction  on  his/her  own.   This  is  a  difficult 
process  at  best  and  it  usually  requires  several  iterations 
before  it  is  done  correctly. 

Currently,  application  developers  must  rely  on  their  own 
memory,  search  through  system  manuals,  or  query  a  fellow 
programmer  (the  duty  expert)  when  developing  applications  to 
insure  that  all  related  aspects  of  a  transaction  are 
addressed  in  their  application.   This  can  take  an  inordinate 
amount  of  time  in  the  case  of  searching  through  system 
manuals,  and  typically  ties  up  two  programmers  when 


consulting  the  duty  expert.   When  this  happens,  nothing  is 
done  to  reduce  the  programming  burden  being  faced  throughout 
the  data  processing  community.   An  expert  system  with  access 
to  a  tool  box  of  logical  transactions  can  eliminate  much  of 
this  duplication  of  effort  in  identifying  and  coding  all  of 
the  related  aspects  of  a  transaction.   Another  benefit  of 
using  an  expert  system  to  access  a  tool  box  of  logical 
transactions  is  that  the  testing  of  the  code  that  makes  up 
the  transactions  has  already  been  accomplished.   Using  code 
that  has  already  been  debugged  will  reduce  the  amount  of 
time  it  takes  to  test  a  program  containing  these  logical 
transactions. 

Expert  systems  technology  will  also  help  to  address  the 
problem  of  loosing  personnel  through  Permanent  Change  of 
Station  Orders.   With  an  expert  system  in  place,  much  of  the 
expert's  knowledge  will  remain  behind  when  he/she  is 
transferred.   This  will  aid  in  the  training  of  new  personnel 
on  the  system  and  speed  up  the  development  of  applications 
as  well. 

The  CFESA  provides  an  excellent  environment  in  which  to 
implement  an  expert  based  system.   It  provides  a  single 
system  image  for  the  user  to  work  in  that  will  be  familiar 
to  him/her  no  matter  where  he/she  is  operating  from.   The 
access  to  a  tool  box  of  common  functions  is  already  in  place 
within  CFESA,  with  the  only  addition  required  being  the 


decision  logic  and  rule  processing,  and  the  inference 
mechanism  to  drive  the  system.   Adding  an  expert  system  that 
will  drive  the  initial  transaction  identification  process 
for  a  system  should  allow  for  additional  increases  in 
productivity  over  and  above  the  38%  increases  achieved  by 
the  DOE  INEL. 

The  addition  of  a  DSS  to  the  manpower  and  pay  arena  will 
provide  a  developer  with  a  series  of  transactions  that  are 
applicable  to  the  project  he/she  is  working  on  based  on  the 
specifications  provided.   A  developer  will  then  refine  and 
combine  the  initial  logical  transactions  to  produce  a 
prototype  system  for  a  user  to  evaluate  and  comment  on. 
This  will  provide  a  developer  with  an  immediate  time  savings 
at  the  beginning  of  a  project  by  giving  him/her  a  starting 
base  for  the  application.   Through  the  use  of  the 
Application  Developers  DSS  and  prototyping  for  developing 
new  systems  end  users  should  be  able  to  reap  the  benefits  of 
a  new  application  earlier  than  under  current  development 
methods,  and  application  developers  should  finally  be  able 
to  reduce  the  backlog  of  development  requests  he/she  is 
currently  facing. 

In  many  cases,  it  is  difficult  to  evaluate  the 
effectiveness  of  a  DSS,  but  when  dealing  with  a  DSS  of  the 
expert  system  variety  it  is  often  much  easier.   Evaluation 
of  the  Application  Developers  DSS  should  be  easy  to 


accomplish  by  comparing  the  current  backlog  of  application 
development  requests  with  the  backlog  of  requests  after  the 
system  is  in  place.   A  reduction  of  the  turnaround  time  for 
application  development  should  be  evident  after  the  system 
is  in  place.   Additionally,  the  CFESA  provides  the 
capability  to  monitor  the  actions  taken  by  any  user  or 
system  operating  within  its  environment.   This  serves  two 
purposes;  it  provides  an  audit  trail  to  track  actions  within 
the  system,  and  the  ability  to  generate  system  wide 
statistics  for  the  computer  centers  operation  staff  to  use 
to  refine  the  systems  operation.   It  can  also  provide  the 
basic  statistics  for  system  budgeting  and  cost  accounting. 
The  use  of  the  system  monitor  to  record  access  information 
for  the  Application  Developers  DSS  to  the  tool  box  would 
give  an  indication  of  the  number  of  accesses  the  Application 
Developers  DSS  makes  to  the  tool  box  and  the  average  number 
of  transactions  each  access  to  the  tool  box  generates. 
These  statistics  can  easily  be  compared  to  current 
development  metrics  such  as  lines  of  code  to  determine  the 
efficiency  of  the  Application  Developers  DSS  in  developing 
applications. 

The  creation  of  a  DSS  to  aid  application  development 
personnel  will  entail  definition  of  specific  tool  box 
functions  and  the  decision  logic  and  rule  processing  to  be 
used  by  the  DSS.   Its  purpose  is  to  aid  development 


personnel  in  gaining  access  to  the  data  and  functions  they 
need  in  their  programs  to  meet  the  needs  of  the  end-users. 
Once  the  initial  prototyping  of  the  system  is  complete,  it 
is  anticipated  that  system  development  will  follow  two  paths 
concurrently: 

•  Further  development  within  the  Manpower  and  Pay 
functional  area 

•  Expanded  functional  area  support  by  being  used  as  a 
basic  framework  for  personnel  to  use  in  developing 
expert  systems  to  support  efforts  in  the  fiscal  and 
logistical  support  functional  areas 

Within  the  manpower  and  pay  arena,  interest  already 
exists  in  developing  expert  systems  to  support  end-users  in 
individual  applications.   The  Application  Developers  DSS 
will  provide  the  basic  mechanisms  and  specific  tool  box 
functions  that  will  be  necessary  to  drive  these  specific 
applications. 

Subsequent  chapters  detail  specific  aspects  for  a  DSS  to 
aid  application  developers  in  the  manpower  and  pay  arena. 

•  Chapter  2  describes  the  basic  background  concerning 
application  development  within  the  Marine  Corps  and  the 
basic  characteristics  of  a  DSS  as  well 

•  Chapter  3  addresses  the  current  environment  at  the 
MCCDPA  Kansas  City,  Missouri  and  the  addition  of  the 
Common  Front  End  System  Architecture 

•  Chapter  4  addresses  the  decision  logic  and  rule 
processing  that  will  drive  the  functioning  of  the  DSS 

•  Chapter  5  outlines  the  components  in  the  model/knowledge 
base  of  the  DSS 

•  Chapter  6  covers  the  functional  requirements  definition 
of  the  proposed  DSS 


Chapter  7  addresses  the  integration  of  the  data,  dialog, 
and  modeling  capabilities  within  the  Common  Front-End 
System  Architecture 

Chapter  8  addresses  the  Conclusions  and  Recommendations 
concerning  the  development  of  the  Application  Developers 
Decision  Support  System 
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II.   BACKGROUND 


A.   DSS  ROLE  AND  ENVIRONMENT 

Identifying  all  the  aspects  of  what  appears  to  be  a 
simple  transaction  can  become  an  elaborate  and  incredibly 
complicated  task  in  a  large  scale  information  systems 
development  project.   Many  sources  must  be  checked  to 
discover  all  the  elements  that  might  be  effected  by  a  single 
transaction,  such  as  a  promotion,  and  most  organizations 
have  strict  guidelines  that  must  be  followed  during  the 
software  development  project.   It  often  takes  a  junior 
programmer  many  hours  of  exhaustive  research  coupled  with 
several  iterations  of  coding  and  testing  before  it  is 
correct. 

Information  systems  development  projects  within  the 
Marine  Corps  are  currently  governed  by  Marine  Corps  Order 
P5231.1A:  Life  Cycle  Management  For  Information  Systems 
Projects,  and  IRM-5231-01:  Information  Resources  Management 
System  Development  Methodology  -  Overview.   The  primary  area 
of  concern  addressed  by  these  documents  is  the  large  scale 
mainframe  database  developments  using  the  MCDN.   During 
project  development,  analysts  and  programmers  are  required 
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to  follow  the  specification  contained  in  these,  and 
subsequent  documents,  in  addition  to  trying  to  meet  the 
needs  of  the  end-user  for  whom  the  program  is  being 
developed. 

Care  must  be  taken  during  development  to  ensure  that  all 
aspects  of  a  transaction  are  dealt  with  properly  and 
completely.   In  the  manpower  and  pay  arena,  a  single 
transaction  may  effect  elements  contained  in  two  separate 
ADABAS  physical  files.   Identifying  all  the  aspects 
contained  within  one  transaction  can  take  an  enormous  amount 
of  time  and  effort  on  the  part  of  a  junior  programmer. 
Numerous  sources  exist  for  identifying  the  data  affected  by 
a  transaction,  including  other  Marine  Corps  Orders, 
previously  developed  programs,  and  any  duty  experts  that  may 
be  available  for  the  programmer  to  consult.   When  the 
frequent  movement  of  personnel  is  taken  into  account,  it  is 
often  a  miracle  that  anything  is  accomplished  at  all.   Any 
expertise  that  an  analyst  or  programmer  may  develop  during 
his  tour  at  an  installation  is  often  lost  when  he/she  moves 
on  to  another  site,  and  there  is  no  guarantee  that  his/her 
replacement  will  come  in  with  anywhere  near  his/her  level  of 
knowledge.   This  means  that  each  new  programmer  must  often 
re-learn  the  knowledge  that  an  outgoing  expert  has  developed 
with  minimal  turnover  involved.   All  the  factors  that  must 
be  considered  during  the  development  process  add  to  the 
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complexity  of  the  task,  and  tend  to  increase  the  amount  of 
time  required  in  the  development  process. 

The  CFESA  environment  provides  a  good  basis  for 
developing  a  DSS.   The  single  system  image  and  the 
consistent  access  format  are  well  equipped  to  be  adapted  for 
use  as  the  dialog  manager  within  a  DSS.   Once  the 
development  system  is  invoked,  a  query/ response  type  of 
dialogue  can  be  initiated  within  the  CFESA  to  provide  the 
DSS  with  the  information  it  needs  to  access  the  tool  box. 
The  tool  box  of  common  functions  within  the  CFESA  will 
provide  the  model  base  of  logical  transactions.   Once  the 
system  has  received  the  input  from  the  developer,  it  will 
access  the  tool  box  and  provide  the  developer  with  a  list  of 
the  transactions  necessary  to  complete  some  aspect  of  an 
automated  process.   The  CFESA  also  provides  a  facility  for 
performing  maintenance  on  the  tool  box  that  will  allow  for 
modification  of  and  additions  to  the  logical  transactions 
throughout  the  life  of  the  system.   The  database  portion  of 
an  expert  system  is  different  than  what  is  considered  the 
database  portion  of  a  DSS.   Within  an  expert  system,  all  the 
database  portion  is  used  for  is  a  temporary  work  space  to 
use  while  collecting  and  collating  the  users  input  and  the 
system  responses.   This  can  be  provided  quite  easily  by 
utilizing  some  temporary  working  storage  for  the  user  during 
the  operation  of  the  system.   The  CFESA  also  provides  a 
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suitable  environment  within  which  to  build  the  decision 
logic  and  rule  processing  that  is  necessary  to  power  the 
inference  engine  within  an  expert  system. 

A  DSS  to  support  application  developers  will  fill  the 
role  of  a  duty  expert  within  a  functional  area  such  as 
manpower  and  pay.   When  provided  with  the  specifics  of  an 
application,  it  will  be  able  to  access  the  tool  box  and 
provide  the  user  with  a  list  of  potential  transactions  much 
faster  than  the  user  could  develop  on  his  own.   In  this  way, 
it  will  serve  to  lessen  the  impact  of  experienced 
programmers  being  transferred  to  other  installations.   Using 
a  query/response  format  to  obtain  the  required  input  from 
the  user  will  allow  the  system  to  function  much  like  a  duty 
expert.   The  decision  logic  and  rule  processing  within  the 
inference  mechanism  could  utilize  data  driven  forward 
chaining  in  order  to  identify  all  the  applicable  data 
elements,  functions  and  procedures  to  meet  the  needs  of  the 
transaction.   A  secondary  benefit  that  will  be  realized  by 
the  use  of  an  expert  system  is  the  faster  development  and 
training  of  junior  programmers.   The  system  will  help  less 
experienced  programmers  to  obtain  a  grasp  of  the  functions 
and  related  attributes  within  a  given  functional  area.   It 
will  accomplish  this  without  removing  a  second  programmer 
from  his/her  development  efforts  as  is  normally  the  case 
when  a  real  duty  expert  is  consulted  for  information. 
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Moreover,  such  a  DSS  is  expected  to  have  a  major  impact 
on  the  amount  of  time  required  for  project  development.   It 
will  reduce  the  amount  of  time  required  to  identify  all  the 
aspects  of  an  automated  process  and  provide  an  increase  in 
programmer  efficiency  by  allowing  them  to  efficiently 
utilize  a  pre-programmed  library  of  common  functions. 
Performance/ impact  of  the  system  should  be  readily  assessed 
by  an  increase  in  programmer  productivity  and  a  reduction  in 
the  amount  of  time  a  users  request  for  an  application  spends 
in  the  development  process.   Use  of  the  expert  system  can  be 
measured  within  the  CFESA  by  utilizing  a  transaction  log 
type  of  facility  available  within  CFESA  to  record  the  number 
of  accesses  made  to  the  system  and  the  amount  of  time 
required  for  the  system  to  process  a  request.   This 
information  can  be  compared  with  the  increase  in  programmer 
productivity  to  determine  how  effective  the  system  is  at 
fulfilling  the  role  of  a  duty  expert  within  a  given 
functional  area. 

B.   DSS  DESIGN  AND  IMPLEMENTATION  PLAN 

The  design  of  the  Application  Developers  Decision 
Support  System  differs  somewhat  from  methods  used  for 
designing  MIS.   Traditional  design  methodologies  (i.e. 
flowcharts,  HIPO)  have  proven  deficient  for  developing  a  DSS 
(Sprague  and  Carlson,  1982) .   Structured  design 
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methodologies  often  result  in  a  mismatch  between  the 
capabilities  of  the  DSS  and  the  requirements  of  decision 
makers  or  decision  making.   They  do  not  have  balanced 
strength  in  dialog,  data,  and  modeling  capabilities  because 
users  cannot  specifically  define  the  decision  support 
requirements  in  advance.   An  approach  to  systems  analysis 
which  is  intended  to  identify  requirements  in  the  dialog, 
data  and  modeling  capability  areas  of  a  DSS  is  based  on  a 
set  of  four  user-oriented  entities:  Representations, 
Operations,  Memory  Aids  and  Control  Mechanisms  (ROMC) . 
Representations  help  conceptualize  and  communicate  the 
problem  or  decision  situation;  operations  analyze  and 
manipulate  those  representations;  memory  aids  assist  the 
user  in  linking  the  representations  and  operations;  and 
control  mechanisms  allow  the  user  to  handle  and  use  the 
system.   This  approach  to  system  analysis  is  known  as  the 
ROMC  approach.   It  is  a  process-independent  method  that 
helps  to  reduce  the  gap  between  decision  support 
requirements  and  DSS  capabilities  (Sprague  and  Carlson, 
1982;  Turban,  1988) . 
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Since  the  system  is  based  on  expert  systems  technology, 
a   hybrid  of  DSS,  the  components  that  make  up  the  system 
differ  from  other  DSS.   To  the  extent  possible,  a  complete 
Representations,  Operations,  Memory  Aids,  and  Control 
Mechanisms  description  of  the  system  follows: 

1.  Representations 

•  Data  Dictionaries 

•  Marine  Corps  Orders 

•  System  Manuals 

•  Existing  Programs 

•  Other  Programmers 

2 .  Operations 

•  Spider  Diagram  of  Related  Functions  (Barrett  and 

Beerel,  1988) 

•  Event  Screen  Maps  (Planning  Analysis  Corporation, 

1988) 

3.  Memory  Aids 

•  Tool  Box  of  Common  Functions 

4.  Control  Mechanisms 

•  Common  Front-End  System  Architecture 

•  Decision  Logic  and  Rule  Processing 
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The  Representations  comprise  all  the  sources  that  a 
programmer/analyst  has  at  his/her  disposal  to  consult  during 
application  development.   An  in  depth  review  of  these 
sources  is  necessary  to  identify  all  the  elements  that  are 
related  to  a  specific  transaction  so  that  the  relations  can 
be  included  in  the  tool  box  of  common  functions. 

The  Operations  required  in  the  system  are  shown  in  the 
Spider  Diagrams  contained  in  Appendix  A  and  the  Event  Screen 
Maps  contained  in  Appendix  B.   Appendix  A  details  the 
sequence  of  events  for  one  leg  of  the  entire  system  and 
Appendix  B  contains  diagrams  detailing  all  the  events  in  the 
system.   Implementing  these  operations  will  allow  the  user 
to  provide  the  specifications  necessary  to  access  the  tool 
box  and  determine  the  data  elements,  functions  and 
procedures  that  may  be  applicable  to  the  type  of  application 
he/she  is  developing. 

The  Memory  Aids  contained  in  the  tool  box  of  common 
functions  represent  all  the  related  aspects  of  a  transaction 
as  identified  by  the  objects  listed  in  the  Representations. 
By  referring  to  the  tool  box  an  application  developer  can 
quickly  identify  all  the  related  data  elements  and  save  the 
time  that  would  have  initially  been  spent  on  searching 
through  the  manuals  to  find  them. 
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The  Control  Mechanisms  for  the  proposed  system  are 
contained  within  the  Common  Front-End  System  Architecture 
and  the  rule  processing  and  decision  logic  utilized  in  the 
inference  mechanisms  processing.   The  CFESA  provides  the 
environment  within  which  the  entire  system  functions,  and 
the  update  and  access  mechanisms  for  the  tool  box  of  common 
functions.   Additionally,  the  CFESA  provides  for  the  smooth 
integration  of  all  the  aspects  of  the  expert  system.   The 
rule  processing  and  decision  logic  control  the  processing  of 
the  inference  mechanism  for  the  system.   The  decision  logic 
will  be  used  to  drive  a  query/response  dialogue  with  the 
system  user  to  provide  the  initial  input  to  the  inference 
mechanism.   The  inference  mechanism  will  then  utilize  that 
input  to  search  through  the  model  base  to  identify  the 
related  data  elements,  functions  and  procedures  within  the 
tool  box  for  an  application  developers  use. 

Functionally,  the  Application  Developers  DSS  will 
include  dialogue,  data  and  modeling  components  as  follows: 
•  Dialog  Component 

The  DSS  dialog  will  be  handled  in  a  Query/Response 
format  where  the  system  queries  the  user  to  gather  input 
concerning  the  area  of  application  to  use  to  drive  the 
inference  engine.   A  typical  session  between  the  system 
(DSS)  and  an  application  developer  (AD)  might  begin  as 
follows: 
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DSS:    What  is  the  primary  functional  area  of  the 

application? 

1.)  MANPOWER. 

2 . )  PAY . 

3 . )  BOTH . 
AD:   1. 
DSS:  What  is  the  type  of  transaction  to  be  performed? 

1. )  Add  a  record. 

2.)  Delete  a  record. 

3.)  Output  a  record. 

4.)  Update  a  record. 
AD:   4. 
DSS:  What  is  the  primary  element  of  concern? 

1.)  Grade  change. 

2 . )  Duty  status. 

3.)  Dependents  status. 

4.)  Local  commanders  information. 
AD:   1. 
DSS:  What  type  of  grade  change? 

1 . )  Promotion. 

2 . )  Demotion. 
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Using  this  style  of  dialog  will  allow  the  system  to 
obtain  the  information  it  requires  to  function,  and  will 
do  so  in  a  manner  that  is  easy  for  even  novice  users  to 
understand  and  respond  to.   It  also  allows  the  system  to 
respond  to  queries  from  the  users  asking  for 
explanations  why  a  specific  question  is  being  asked  or 
how  the  system  reached  a  particular  conclusion. 

•  Data  Component 

Normally,  the  data  component  of  a  DSS  is  represented 
by  a  database  of  one  type  or  another.   Within  the 
Application  Developers  DSS,  the  database  serves  as  a 
temporary  working  storage  space  where  it  acts  upon  the 
inputs  from  the  user  and  combines  them  with  the  tool  box 
components  in  order  to  respond  to  the  users  request. 

•  Model  Component 

The  model  component  represents  the  knowledge  store 
within  the  system.   Within  the  Application  Developers 
DSS  the  knowledge  is  represented  by  the  rule  processing 
and  decision  logic  working  in  conjunction  with  the 
components  contained  in  the  tool  box  of  common 
functions.   The  CFESA  provides  the  facility  to  make 
changes  to  the  model  base  allowing  the  system  to  grow 
and  adapt  to  the  needs  of  the  users. 
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Figure  2-1  contains  a  diagram  showing  how  the  resources 
available  within  the  DSS  environment  are  mapped  onto  the 
functional  components  described  above.   The  CFESA  provides 
the  framework  within  which  the  DSS  functions  as  a  whole,  and 
it  also  provides  key  components  for  use  by  the  individual 
Dialogue  and  Model  components.   Additionally,  the  model 
component  contains  the  heart  of  the  DSS,  the  tool  box  of 
common  functions  and  the  inference  mechanism.   These  two 
items  are  the  parts  of  the  system  that  actually  simulate  the 
reasoning  of  a  duty  expert  to  provide  a  response  to  a  users 
request.   While  the  user  may  view  the  dialogue  component 
he/she  deals  with  as  the  system,  the  majority  of  the  design 
effort  is  centered  here  to  provide  accurate  and  meaningful 
results.   The  data  component  shown  on  the  map  actually  holds 
a  minimal  amount  of  data  in  the  form  of  the  decision  logic 
and  rule  processing.   There  is  some  interface  between  the 
functional  area's  data  dictionary  and  the  tool  box  of  common 
functions.   This  is  accomplished  within  the  temporary  work 
space  that  is  designated  within  the  expert  system  in  order 
to  handle  the  users  input  and  formulate  the  systems  replies 
to  the  users  queries. 
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Figure  2-1  CFESA  Components 

Figure  2-2  contains  a  diagram  showing  how  the 
implementation  process  for  an  expert  system  should  be 
handled.   The  most  important  activities  within  the  process 
are  acquiring  and  structuring  the  knowledge.    This  is  the 
time  when  you  are  working  closely  with  the  duty  expert  and 
potential  users  trying  to  adapt  the  system  to  meet  their 
needs.   Care  must  be  taken  during  this  phase  to  insure 
cooperation  between  all  parties.   Again  it  is  important  to 
remember  that  this  is  an  iterative  process,  as  depicted  in 
the  diagram,  and  change  is  expected  to  occur. 
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Figure  2-2  Implementation  Process 


(Barrett  &  Beerel,  1988) 
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III.   ENVIRONMENT 

A  recent  study  (Peat,  Marwick,  Main  &  Co.,  1987) 
analyzed  the  benefits  of  a  user  interface  that  was  found  to 
be  easy  to  use.   The  benefits  identified  by  the  study  fell 
into  four  broad  areas. 

•  Productivity  gains  were  realized  by  an  improvement  in 
throughput,  increased  quality  of  product,  and  improved 
planning,  communications,  and  control  due  to  a  system 
that  was  easy  to  use 

•  Ease  of  use  was  found  to  be  an  asset  in  a  system  since 
it  promoted  use  of  the  system  rather  than  acted  as  a 
roadblock  to  the  users 

•  Ease  of  training  made  the  system  easier  for  the  users  to 
get  started  with  and  once  they  had  learned  one 
application  it  was  easy  to  add  on  others  since  they  had 
the  same  feel  due  to  a  common  interface 

•  Executive  use  of  the  system  was  found  to  be  enhanced  as 
a  result  of  the  ease  of  use  and  ease  of  training 
features.   The  ability  to  quickly  master  the  operation 
of  a  system  allowed  key  executives  to  plan,  communicate, 
and  control  their  projects  and  resources  which  provides 
competitive  and  strategic  value  to  an  organization 

The  benefits  identified  in  the  study  are  summarized  in 

Table  3.1. 
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Good  User  Interface  Benefits 

Productivity  Gains 

-  Throughput  gains. 

-  Quality  gains. 

-  Planning,  Communications,  and  Control  gains. 

Ease  of  use  promotes  use. 
Ease  of  training. 
Executive  use. 


Table  3.1  Interface  Benefits 

The  ability  of  an  easy  to  use  interface  to  increase 
productivity  and  promote  use  of  a  system  is  the  reason 
behind  the  inception  of  the  Common  Front  End  System 
Architecture  (CFESA) . 

The  CFESA  is  scheduled  for  implementation  at  the  MCCDPA 
Kansas  City,  Mo.  during  the  fall  of  1989.   The  environment 
that  it  will  be  operating  on  is  contained  in  Table  3.2. 
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HARDWARE: 

SOFTWARE: 

IBM  3084  Quad  Processor 

MVS/XA 

IBM  3380  DASD 

Top  Secret 

NCR  Comten  Front  end  Processor 

UCC  -  7 

Line  Printers 

UCC  -  11 

Tape  Drives 

VTAM 
TSO/E 

Other  associated  peripherals 

CICS 

ROSCOE 

COMPLETE 

Natural  2.1 

Adabas  5.0 

Other  miscellaneous  compilers 

utilities  and  application 

packages 

Table  3.2  MCCDPA  Environment 


The  CFESA  is  designed  to  standardize  the  computer 
interface  and  provide  a  single  system  image  within  a 
computing  environment.   The  primary  goal  of  the  single 
system  image  is  to  provide  a  friendlier,  easier  to  use 
interface  that  promotes  system  use  rather  than  acts  as  an 
obstacle  to  it. 

The  CFESA  is  centered  around  a  menu  system  that  provides 
a  user  with  a  unique  choice  of  functions  based  on  what 
he/she  is  authorized  to  access.   The  menu  system  is  flexible 
in  the  sense  that  it  allows  novice  users  the  ability  to  step 
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down  through  each  level  of  menus  to  get  to  the  function  or 
data  he/she  needs  to  access,  yet  will  allow  an  experienced 
user  to  do  a  direct  transfer  to  the  function  or  data  without 
utilizing  each  of  the  intermediate  steps.   The  security 
facility  within  the  CFESA  is  provided  by  a  centralized 
security  file  that  is  accessed  each  time  a  user  logs  onto 
the  system.   The  specific  access  level  for  the  user  is 
contained  in  the  file  and  determines  what  functions  he/she 
is  provided  within  his/her  menu  structure.   This  further 
enhances  system  security  by  preventing  a  user  from  seeing 
functions  that  he/she  is  not  authorized  to 
access. (Linsenman,  1987) 

Additionally,  personnel  are  provided  access  to 
development  aids  in  the  form  of  a  tool  box  of  common 
functions  that  can  significantly  reduce  program  development 
and  maintenance  time.   One  such  aid  is  the  standard 
navigational  capabilities  given  to  the  user  through  the  use 
of  Program  Function  (PF)  Keys.   Actions  such  as  the 
immediate  log-off  from  the  system,  transfer  to  any  other 
authorized  transaction  in  the  system,  and  return  to  the 
previous  menu  are  effected  with  a  single  keystroke. 
(Linsenman,  1987)   The  ability  to  utilize  these  aids  saves 
time  on  the  users  part  and  provides  a  quick  and  standard 
method  of  execution  which  further  enhances  the  single  system 
image.   Table  3.3  contains  a  summary  of  the  functionality 
provided  by  the  CFESA. 
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SYSTEM  ARCHITECTURE  CONCEPT 

*  SINGLE  SYSTEM  IMAGE 

-  ONE  LOGON  PROVIDES  ALL  ACCESS 

-  CONSISTENT  USER  INTERFACE 

#  STANDARD  MENU  SCREENS 

#  COMMON  AUDIT  FUNCTIONS 

#  COMMON  HELP  AND  ERROR  HANDLING 

#  STANDARD  USE  OF  KEYBOARD 

-  MACHINE  INDEPENDENT 

-  SOFTWARE  INDEPENDENCE 

-  INTRA-APPLICATION  COMMUNICATIONS 

*  SECURITY  CONCEPT 

-  STANDARD  SECURITY  IAW  TOP  SECRET 

*  INTEGRATED  DATA  RESOURCE 

-  REAL  FAMMIS  DATA  BASE 

-  CURRENT  DATA  BASES 


Table    3.3    CFESA    Concept 

The   tool   box   is   centered  on  a   logical   transaction 
concept  which   is   defined  as   the  minimum  amount   of  work 
required   to   perform   some   aspect   of   an   automated   process. 
Each   transaction   or  process  within   a   system   is   analyzed   to 
determine   what   actions   are   associated  with    it.      Once 
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identified,  they  are  used  to  define  the  logical  transaction 
that  is  contained  in  the  tool  box.   Once  the  logical 
transaction  is  defined,  the  developer  does  not  need  to  rely 
on  his/her  memory  or  spend  time  tracking  through  system 
manuals  to  ensure  that  a  transaction  he/she  requires  for  an 
application  is  complete.   He/she  simply  accesses  the  tool 
box  for  the  transaction  and  is  insured  of  the  atomicity  of 
the  transaction  based  on  its  presence  in  the  tool  box.   If 
five  records  need  to  be  created  to  add  an  item  to  a 
database,  then  the  creation  of  the  five  records  is  a  logical 
transaction.   Any  less  data  indicates  an  incomplete 
transaction,  and  any  more  indicates  a  repeat  of  the 
transaction.  (Linsenman,  1987)   By  storing  the  composition 
of  the  logical  transaction  in  the  tool  box,  the  user  is 
insured  that  all  aspects  of  the  transaction  are  dealt  with 
whenever  it  is  accessed. 

Other  standard  functions  provided  to  the  user  by  the 
CFESA  are:  help,  data  verification,  transaction  reporting 
(audit  trail) ,  transaction  activation,  common  transaction 
linkage  between  applications  and  functions,  and  standardized 
PF  keys. 

A  DSS  based  within  the  CFESA  would  provide  added 
functionality  to  application  developers  in  identifying  the 
necessary  components  from  the  tool  box  for  their 
application.   The  addition  of  a  manpower  and  pay  DSS  to  the 
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CFESA  is  expected  to  significantly  reduce  the  time  and 
effort  that  currently  is  required  to  develop  end-user 
applications  by  reducing  the  time  an  application  developer 
spends  in  identifying  the  components  required  for  his/her 
application.   It  will  provide  a  developer  with  a  series  of 
transactions  that  are  applicable  to  the  project  he/she  is 
working  on  based  on  the  project  specifications  that  the 
developer  provides.   The  developer  will  then  refine  and 
combine  the  initial  logical  transactions  to  produce  a 
prototype  system  for  the  user  to  evaluate  and  comment  on. 
This  will  provide  the  developer  with  an  immediate  time 
savings  at  the  beginning  of  a  project  by  giving  him/her  a 
starting  base  for  the  application.   Through  the  use  of  the 
Application  Developers  DSS  and  prototyping  for  developing 
new  systems  the  user  will  be  able  to  reap  the  benefits  of 
his/her  new  application  more  quickly  than  under  current 
development  methods,  and  developers  should  finally  be  able 
to  begin  making  headway  against  the  backlog  of  development 
requests  he/she  is  currently  facing. 

The  primary  components  of  a  DSS  within  the  CFESA  would 
be  the  dialog  component  and  a  knowledge  base  to  store  the 
necessary  information  to  drive  the  system  outputs.   These 
components  can  be  easily  incorporated  into  the  structure  of 
the  CFESA.   The  menu  structure  of  the  CFESA  environment 
provides  an  excellent  mechanism  for  implementing  a  dialogue 
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with  the  user  and  the  tool  box  of  common  functions  provides 
a  storage  area  for  the  knowledge  base. 

The  dialog  component  implemented  within  the  CFESA  menu 
structure  would  contain  the  essence  of  the  system.   The 
decision  logic  and  rule  processing  would  be  contained  within 
the  user  interface  to  determine  the  initial  data 
requirements  from  the  tool  box.   The  user  would  be  presented 
with  a  series  of  questions  that  he/she  would  have  to  respond 
to.   Once  all  of  his/her  responses  are  entered,  the  system 
would  utilize   forward  chaining  to  work  through  the 
statements  contained  within  the  inference  engine  of  the  DSS 
to  determine  the  tool  box  access  requirements. 

The  knowledge  base  would  be  stored  within  the  tool  box 
of  common  functions  in  the  form  of  data  element 
relationships,  standardized  function  modules  and  pre- 
programmed procedures  that  would  be  accessed  based  upon  the 
results  of  the  user/system  dialog.   These  data  element 
relationships,  standardized  function  modules  and  pre- 
programmed procedures  would  provide  the  application 
developer  with  a  knowledge  base  to  build  upon  for  the 
development  of  his/her  application  much  faster  than  he/she 
could  develop  that  knowledge  base  by  sifting  through 
reference  manuals  and  other  information  sources. 
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IV.   DECISION  LOGIC  &  RULE  PROCESSING 

The  decision  logic  and  rule  processing  used  to  drive  the 
inference  mechanism  of  a  DSS  comprises  the  data  and  dialog 
components  of  the  Application  Developers  DSS.   The  inference 
mechanism  is  the  bridge  between  the  user  and  the 
model/knowledge  base  that  leads  the  user  to  the  information 
or  knowledge  that  he/she  needs  to  get  from  the 
model/knowledge  base.   Figure  4.1  shows  the  relationship 
between  the  user,  inference  mechanism,  knowledge  base  and 
database. 

The  inference  mechanism  drives  all  interaction  within 
the  system.   Its  function  is  to  use  the  decision  logic  and 
rule  processing  to  search  through  the  knowledge  base  to 
provide  information  to  a  user.   The  inference  mechanism  is 
basically  a  set  of  routines  that  carry  out  deductive 
reasoning.   It  has  no  understanding  what  it  is  doing,  or 
what  it  achieves.   The  process  is  simply  a  mechanical  one. 
(Barrett  and  Beerel,  1988) 
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Figure  4 . 1  Component  Relationship 

An  inference  mechanism  is  typically  composed  of  a  series 
of  IF-THEN-ELSE  statements  that  step  the  user  through  the 
decision  making  process  to  obtain  the  relevant  information 
contained  within  the  systems  knowledge  base.   Information 
can  be  obtained  from  the  knowledge  base  by  using  one  of  two 
methods  of  working  through  the  decision  logic  and  rule 
processing.   The  inference  mechanism  can  use  goal  directed 
reasoning  which  is  known  as  backward  chaining  or  it  can  use 
data  driven  reasoning  which  is  known  as  forward  chaining  to 
thread  through  the  rules.   With  backward  chaining,  the  goals 
are  possible  solutions  to  a  specific  problem  and  the  system 
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works  backward  through  the  rules  associated  with  each  goal 
to  determine  if  it  is  a  viable  alternative.   Forward 
chaining  uses  the  strategy  of  gathering  data  from  a  user 
until  a  pattern  is  recognized  that  will  allow  the  system  to 
present  a  user  with  a  solution  set.   Forward  chaining  leads 
to  a  wider  variety  of  solutions  than  does  backward  chaining 
since  the  possible  solutions  are  not  specified  before  hand. 
The  chaining  method  used  by  a  DSS  depends  upon  the  purpose 
of  the  DSS.   Backward  chaining  is  most  useful  in  selecting 
between  a  set  of  known  solutions,  and  forward  chaining  is 
used  for  building  up  solutions  and  leaps  in  reasoning.   Each 
of  these  methods  leaves  a  different  impression  on  a  user. 
Figure  4 . 2  shows  a  comparison  between  the  two  types  of 
chaining.  (Barrett  and  Beerel ,  1988) 

Forward  chaining  is  the  logical  choice  when  a  system  has 
to  build  up  a  solution  from  many  components,  or  inputs.   The 
Application  Developers  DSS  would  be  such  a  system.   The  idea 
behind  the  system  is  to  provide  a  developer  with  a  set  of 
data  elements,  procedures  or  functions  that  may  be 
applicable  to  the  application  he/she  is  working  on.   Once 
the  developer  has  a  solution  set  to  start  with,  he/she  can 
begin  to  work  on  narrowing  or  expanding  that  base  to  provide 
all  of  the  information  or  functionality  that  the  application 
he/she  is  working  on  requires. 
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Figure  4.2  Chaining  Comparison 
The  inference  mechanism  also  provides  a  degree  of  self 
documentation  to  the  system.   This  ability  comes  with  the 
systems  ability  to  track  the  rules  that  it  uses  to  reach  a 
conclusion  or  conclusions  and  to  provide  that  list  to  the 
developer  so  that  he/she  can  verify  that  the  rules  the 
system  used  are  all  applicable  to  the  application  he/she  is 
developing.   The  inference  mechanism  also  provides  the 
ability  to  respond  to  basic  type  of  questions  the  user  asks 
such  as  why  a  particular  rule  was  used.   In  this  instance 
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the  system  would  respond  with  the  link  that  caused  that 
particular  rule  to  be  used.   This  self  documenting  aspect  of 
the  system  will  enable  an  application  developer  to  verify 
the  outputs  of  the  system  more  rapidly  than  he/she  would  be 
able  to  verify  them  if  he/she  didn't  have  them. 

One  aspect  of  a  forward  chaining  expert  system  type  of 
DSS  that  is  often  looked  upon  as  a  drawback  to  them  is  the 
unpredictable  nature  of  them.   There  is  no  guarantee  with 
this  type  of  system  that  a  reasonable  solution  set  will  be 
arrived  at.   The  solution  set  that  the  system  provides  may 
have  no  conclusions  in  it  at  all,  or  it  may  have  an 
excessive  number  of  conclusions,  or  an  excessively  large 
solution  set.  (Barrett  and  Beerel,  1988)   While  these  may 
seem  to  be  drawbacks  in  the  beginning,  a  closer  examination 
of  the  purpose  of  the  Application  Developers  DSS  shows  that 
these  results  are  actually  an  added  benefit.   A  solution  set 
that  contains  no  recommendations  for  data  elements, 
procedures  or  functions  or  one  that  is  excessively  large  may 
actually  be  an  indication  that  the  application  that  the 
developer  is  working  on  has  been  poorly  specified  or  poorly 
designed.   Receiving  an  indication  like  this  early  in  a 
projects  life  cycle  should  help  to  shorten  the  development 
time  and  improve  the  quality  of  the  application  as  a  whole. 
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V.   MODEL/ KNOWLEDGE  BASE 

The  model/knowledge  base  is  the  heart  of  an  expert 
system  type  of  DSS.   It  contains  the  know-how  or  expert 
information  of  the  system  that  the  inference  mechanism  must 
act  with  to  reach  a  feasible  solution  based  on  the  users 
input.   The  information  contained  in  the  model/knowledge 
base  can  come  in  any  form,  but  it  is  usually  expressed  in 
the  form  of  rules  of  thumb  or  relationships.   The 
programming  language  used  within  the  system  most  often 
determines  the  form  the  model/knowledge  base  will  take. 
(Barrett  &  Beerel,  1988) 

The  model/knowledge  base  within  the  Application 
Developers  DSS  will  serve  as  the  store  house  of  the  systems 
knowledge.   It  will  hold  the  data  relationships,  procedures 
and  functions  that  will  comprise  the  outputs  of  the  system. 

Access  to  the  model/knowledge  base  will  be  controlled  by 
the  decision  logic  and  rule  processing  utilized  by  the 
dialog  component  of  the  DSS.   As  stated  earlier,  the  rules 
of  the  system  are  stored  in  the  form  of  IF-THEN-ELSE  type 
statements.   This  form  is  a  familiar  form  to  almost  everyone 
literate  in  computers  and  makes  the  logic  of  the  system 
relatively  easy  to  understand.   In  an  expert  system  type  of 
DSS  each  rule  is  a  nugget  of  know-how  which  is  valid  in 
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itself.   When  the  system  is  running  the  inference  mechanism 
will  select  which  rules  to  apply,  and  when,  to  solve  the 
current  problem.   The  system  builder  only  has  to  state  what 
the  rules  are  and  not  how  the  rules  will  be  used.   The 
statement-  of  what  rather  than  how  is  a  declarative  statement 
of  know-how  and  is  one  of  the  strengths  of  an  expert  system 
DSS.   Other  strengths  include: 

•  ability  to  add,  modify,  or  delete  rules  independently  of 
one  another 

•  ability  to  input  rules  in  any  order 

•  program  is  easy  to  understand 

While  these  are  generic  strengths  of  an  expert  system 
DSS,  there  are  some  exceptions  to  them  in  reality.   In  many 
cases  the  order  the  rules  are  input  often  affects  the 
processing,  and  the  ease  of  understanding  is  often  dependent 
on  the  software  tools  used  and  the  skills  of  the  person 
developing  the  system. 

When  compared  to  traditional  systems,  an  expert  system 
type  of  DSS  is  usually  quicker  to  build  and  easier  to 
modify.   It  lends  itself  well  to  incremental  development 
which  gets  a  beginning  product  into  the  users  hands  faster 
and  can  be  modified  faster  to  provide  what  the  user  really 
wants  because  of  the  independent  rules.   (Barrett  &  Beerel, 
1988) 
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Another  primary  aspect  of  the  model/knowledge  base  is 
the  information  it  contains  in  the  form  of  data 
relationships,  canned  procedures  and  standardized  functions. 
In  order  for  the  Application  Developers  DSS  to  assist  a 
developer  in  identifying  all  the  aspects  of  a  transaction  or 
application  it  must  contain  intimate  knowledge  about  what 
the  relationships  are  among  the  data  elements  and  how  a 
change  in  one  can  effect  other  elements.   Information  like 
this  can  be  expressed  in  the  form  of  a  complete,  interactive 
data  dictionary  or  an  Entity  And  Attribute  Report  and 
Association  Report  (Information  Engineering  Systems 
Corporation,  1989) . 

Additionally,  canned  routines,  procedures  and  functions 
should  be  available  as  an  output  from  the  system.   These 
should  come  in  the  form  of  pre-coded  and  debugged  modules 
that  have  proven  to  be  effective  in  solving  a  rigidly 
specified  task.   These  could  include  modules  to  change  a 
service  members  marital  status,  promotion  or  stop/start  an 
entitlement.   The  use  of  pre-coded  modules  like  these  in 
applications  development  will  promote  structured  programming 
techniques,  improve  development  speed  and  ease  the 
documentation  burden  because  each  of  the  modules  should  be 
complete  entities  unto  themselves,  complete  with  test 
results  and  documentation  to  be  included  in  the  final 
package  for  the  user.   The  only  effort  required  by  the 
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developer  would  be  the  function/procedure  call  and  variable 
passing  to  get  the  data  into  and  out  of  the  module. 
In  many  cases,  the  sources  for  the  standardized 
functions  and  procedures  already  exist  in  many 
organizations.   Most  programmers  maintain  their  own  private 
libraries  of  pre-coded  modules  that  execute  what  they  have 
found  to  be  repetitive  or  commonly  used  tasks.   By  tapping 
these  libraries  significant  time  in  loading  the 
model/knowledge  base  can  be  saved  and  many  programmers  would 
feel  that  they  have  a  vested  interest  in  the  system  since 
they  would  have  made  a  contribution  to  it.   This  aspect  will 
go  a  long  way  toward  tapping  the  pool  of  expert  knowledge 
throughout  an  organization. 
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VI.   FUNCTIONAL  REQUIREMENTS  DEFINITION 

This  chapter  contains  the  Functional  Requirements 
Definition  of  the  Application  Developers  DSS  and  is 
formatted  in  accordance  with  Marine  Corps  Order  P52  31.1A  and 
IRM  5231.04. 

SECTION  1  GENERAL 

The  Marine  Corps  Central  Design  and  Programming 
Activity,  Kansas  City,  Mo.  is  currently  installing  a  new 
architecture  for  their  mainframe  environment  to  operate 
under  that  is  known  as  the  Common  Front-End  System 
Architecture.   This  architecture  gives  an  application 
developer  working  within  the  manpower  and  pay  arena  a  single 
system  image  environment  to  operate  within  and  provides 
him/her  with  access  to  a  tool  box  of  common  functions  to  use 
in  developing  applications. 

This  specification  describes  a  DSS  for  use  on  the  CFESA 
that  will  aid  an  application  developer  in  identifying 
applicable  data  elements,  functions,  and  procedures  for  use 
in  a  program  being  developed. 
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1.1  OBJECTIVES 

The  Application  Developers  DSS  design  objectives  are: 

a.  Provide  application  developers  working  within  the 
CFESA  with  an  automated  aid  for  identifying  data 
elements,  functions  and  procedures  that  could  be 
applicable  to  a  program  under  development. 

b.  Save  time  during  the  development  phase  of  a 
programming  project. 

c.  Guard  against  the  loss  of  knowledge  in  the  event 
the  "duty  expert"  leaves  the  installation. 

1.1.1  Current  System  Deficiencies 

The  current  method  of  identifying  applicable  data 
elements,  functions,  and  procedures  to  use  within  a 
programming  project  leads  to  several  deficiencies.   Among 
them  are: 

a.  Excessive  time  spent  searching  through  unrelated 
literature. 

b.  Distracting  knowledgeable  programmers  from  their 
assigned  tasks. 

c.  Missing  related  data  elements,  functions,  or 
procedures  due  to  lack  of  recognizing  their 
applicability. 

d.  Loss  of  corporate  information  when  experienced 
programmers  leave  the  installation. 
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1.1.2  Proposed  System  Objectives 

The  primary  objective  of  the  Application  Developers  DSS 
is  to  provide  application  developers  working  within  the 
CFESA  architecture  an  automated  tool  to  speed  up  the 
identification  of  data  elements,  functions,  and  procedures 
that  need  to  be  considered  for  use  within  a  programming 
project.   The  system  will  use  the  components  of  the  CFESA 
architecture  to  query  an  application  developer  about  the 
focus  of  a  programming  project  and  use  the  results  to  search 
through  the  tool  box  of  common  functions  to  obtain  a 
beginning  set  of  data  elements,  functions,  and  procedures 
that  should  be  considered  as  applicable  to  the  project.   At 
that  point  the  application  developer  must  determine  which  of 
the  items  is  actually  applicable  to  the  project  and  use  them 
accordingly. 
1.2  SCOPE 

The  Application  Developers  DSS  will  be  limited  to  the 
manpower  and  pay  functional  areas  that  are  within  the  domain 
of  the  MCCDPA  Kansas  City,  Mo. 
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1.2.1  Applications  Under  Study 

The  Application  Developers  DSS  will  be  limited  to 
application  development  in  the  manpower  and  pay  functional 
areas.   All  of  the  deficiencies  identified  in  Section  1.1.1 
are  directly  related  to  the  amount  of  time  spent  gathering 
information  and  the  accuracy,  completeness,  and  relevance  of 
the  information. 

1.2.2  Organizational  Environment 

The  organizational  environment  the  system  will  function 
within  is  the  environment  within  the  Marine  Corps  Central 
Design  And  Programming  Activity,  Kansas  City,  Mo. 

1.2.3  Site  Specific  Information 

The  system  will  run  within  the  hardware  and  software 
environment  delineated  previously  in  Table  3.2. 
1.3  AUTHOR 

Captain  Charles  C.  Hansen,  USMC 

Student,  Computer  Systems  Management  Curriculum 

Naval  Postgraduate  School 

Monterey,  Ca.  93943 
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1.4  FUNCTIONAL  REQUIREMENTS  DEFINITION  ACTION  PLAN 

The  Application  Developers  DSS  represents  a  new  type  of 
development  activity  for  the  MCCDPA  Kansas  City,  Mo.   It 
will  replace  a  manual  search  of  system  reference  manuals, 
data  dictionary  entries,  previously  developed  programs,  and 
corporate  knowledge  held  by  other  members  of  the 
organization  with  an  automated  tool  that  will  focus  on  the 
primary  area  of  a  development  project. 
1.4.1  New  Logical  Model  Findings 

The  CFESA  provides  an  excellent  environment  for  a  DSS  to 
operate  within.   It  provides: 

a.  A  well  defined  method  of  user  interface  to  handle 
the  dialog  component  of  a  DSS. 

b.  A  tool  box  for  the  storage  of  data  element 
relationships,  functions,  and  procedures  to  fill  the 
needs  of  the  model  component  of  a  DSS. 

c.  A  temporary  work  area  for  the  system  to  use  as  the 
data  component  to  compile  the  results  of  the 
user/system  dialog  and  search  the  model  component  to 
identify  the  applicable  information. 
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1.4.2  Recommended  Course  of  Action 

The  ability  of  the  CFESA  to  meet  the  needs  of  a  DSS 
indicates  that  development  of  a  DSS  for  application 
developers  working  within  the  CFESA  should  be  undertaken. 
DSS  development  requires  a  different  approach  than 
traditional  system  development  utilizes  in  order  to  be 
successful.   Past  experiences  in  DSS  development  indicate 
that  an  incremental  approach  to  development  through  the  use 
of  prototypes  works  best.  (Sprague  and  Carlson,  1982; 
Turban,  1988) 

Based  on  the  findings,  incremental  development  of  the 
Application  Developers  DSS  should  continue  through  the  use 
of  prototypes. 
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SECTION  2 .  STRUCTURED  SPECIFICATION 
2. 1  DATA  FLOW  DIAGRAMS  (DFD) 

The  DFD's  for  the  Application  Developers  DSS  are 
depicted  in  the  following  sections. 
2.1.1  Context  Diagram 
FIGURE  7-01  Application  Developers  DSS  Context  Diagram 
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Figure  7-01  Context  Diagram 
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2.1.2  Leveled  Set  of  Diagrams 

2.1.2.1  Level-One  Diagram 

FIGURE  7-02  Application  Developers  DSS  Logical  Model 
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Figure  7-02  Logical  Model 
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2.1.2.2  Level-Two  Diagrams 

FIGURE  7-03  Application  Developers  DSS  Dialog  Component 
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Figure  7-03  Dialog  Component 
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FIGURE  7-04  Application  Developers  DSS  Data  Component 
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Figure   7-04    Data   Component 
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2.2  MINI-SPECIFICATIONS 

2.2.1  Mini-Specification  Descriptions 

2.2.1.1  1.0  Application  Developers  DSS  Dialog  Component 

1.1  Obtain  Functional  Area  Info 

1.2  Obtain  Event  Info 

2.2.1.2  2.0  Application  Developers  DSS  Data  Component 

2.1  Identify  Data  Elements 

2.2  Identify  Functions 

2.3  Identify  Procedures 

2.2.2  Level-One 

2.2.2.1  Process  1.0  Application  Developers  DSS  Dialog 
Component 

2.2.2.2  Process  2.0  Application  Developers  DSS  Data 
Component 

2.2.3  Level-Two 

2.2.3.1  Process  1.1  Obtain  Functional  Area  Info 

This  process  is  the  initial  component  of  the  dialog 

component  for  the  DSS  designed  to  obtain  the  desired 

functional  area  from  the  user.   Information  obtained  in  this 

process  is  used  to  determine  the  queries  available  in  the 

next  process. 

Query  user  for  applicable  Functional  Area 
Accept  user  input  for  Functional  Area 
Pass  Functional  Area  to  Process  1.2 
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2.2.3.2  Process  1.2  Obtain  Event  Information 

This  process  uses  the  Functional  Area  information  obtained 
in  Process  1.1  to  determine  the  relevant  event  information 
to  query  the  user  about  that  will  eventually  be  used  to 
select  applicable  data  elements,  functions,  and  procedures. 

Do  while  not  done 

Query  user  for  applicable  events  based  on  Functional 

Area 

Accept  event  input  from  user 
End-do 
Output  Functional  Area/Event  info  to  Process  2 . 0 

2.2.3.3  Process  2.1  Identify  Data  Elements 

This  process  takes  the  data  assembled  in  the  data  component 

of  the  Application  Developers  DSS  and  uses  the  information 

to  search  the  tool  box  of  the  CFESA  for  data  elements  that 

may  be  applicable  to  a  developers  application  that  is  under 

development. 

Accept  FA/Event  data 

Search  tool  box  for  applicable  data  elements 
Store  applicable  data  elements  for  output  to  user 
Pass  FA/Event  data  to  Process  2.2 

2.2.3.4  Process  2.2  Identify  Functions 

This  process  takes  the  data  assembled  in  the  data  component 

of  the  Application  Developers  DSS  and  uses  the  information 

to  search  the  tool  box  of  the  CFESA  for  functions  that  may 

be  applicable  to  a  developers  application  that  is  under 

development. 

Accept  FA/Event  data 

Search  tool  box  for  applicable  functions 
Store  applicable  functions  for  output  to  user 
Pass  FA/Event  data  to  Process  2 . 3 
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2.2.3.5  Process  2.3  Identify  Procedures 

This  process  takes  the  data  assembled  in  the  data  component 

of  the  Application  Developers  DSS  and  uses  the  information 

to  search  the  tool  box  of  the  CFESA  for  procedures  that  may 

be  applicable  to  a  developers  application  that  is  under 

development. 

Accept  FA/Event  data 

Search  tool  box  for  applicable  procedures 
Store  applicable  procedures  for  output  to  user 
Discard  FA/Event  data 

2.3  DATA  DICTIONARY 

The  data  dictionary  developed  and  defined  by  the  REAL  FAMMIS 

project  is  applicable  and  requires  no  changes. 

SECTION  3  SUPPORTING  DOCUMENTATION 
3.1  SUMMARY  OF  NEW  REQUIREMENTS 

The  new  requirements  of  the  Application  Developers  DSS 
lie  in  the  area  of  the  data,  dialog,  and  model  base 
components  of  a  DSS.   These  components  make  up  the  heart  of 
a  DSS  and  specific  information  concerning  each  component  as 
it  relates  to  the  Application  Developers  DSS  is  contained  in 
Chapter  7 . 
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VII.   CFESA  SYSTEM  INTEGRATION 

The  CFESA  is  the  key  ingredient  in  the  development  of 
the  Application  Developers  DSS.   It  provides  an  excellent 
environment  to  support  the  data  and  dialog  components  of  the 
DSS  as  well  as  a  ready  made  store  house  for  the  model  base 
in  the  form  of  the  tool  box.   All  of  the  interfaces  between 
these  components  have  already  been  designed  within  the 
CFESA,  as  well  as  additional  features  that  make  the  user's, 
application  developer's,  and  system  administrator's  jobs 
easier  to  master. 

Tieing  a  DSS  into  the  CFESA  will  require  care  and 
attention  to  be  applied  to  each  individual  component.   Each 
of  the  DSS  components,  Data,  Dialog  and  Model  Base,  has  its 
own  particular  areas  of  concern  that  need  to  be  addressed 
directly. 

A.   DATA  COMPONENT 

The  Data  Component  of  the  DSS  is  where  all  of  the 
decision  making  of  the  DSS  will  occur.   For  the  Application 
Developers  DSS  it  contains  the  rule  base  the  system 
functions  on  and  temporary  working  storage  for  use  while  the 
users  input  is  being  accumulated  and  then  to  store  and 
format  the  results  of  searching  the  tool  box  (Model  Base) 
for  data  elements,  functions  and  procedures  that  might  be 
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applicable  to  a  developers  project.   In  an  environment  where 
virtual  memory  is  used,  such  as  that  found  at  the  MCCDPA, 
concern  over  each  users  available  work  area  is  minimized 
thanks  to  the  dynamic  way  in  which  memory  is  allocated  to 
each  userv   In  installations  where  virtual  memory  is  not 
utilized,  or  there  are  other  restrictions  imposed  upon 
user's  memory  use,  care  should  be  taken  to  allocate 
sufficient  memory  to  allow  for  the  efficient  processing  of 
the  system.   If  there  isn't  enough  memory  allocated  to  allow 
for  smooth,  efficient  operation  the  system  will  appear  slow 
and  awkward  to  a  user  and  will  result  in  a  lack  of 
confidence  in  the  responses  the  system  provides  and 
eventually  use  of  the  system  will  cease.  (Barrett  and 
Beerel,  1988) 

The  rule  base,  in  the  form  of  IF-THEN-ELSE  statements, 
contains  the  reasoning  ability  of  the  DSS.   They  are  an 
attempt  to  isolate  the  reasoning  that  an  experienced 
programmer  might  utilize  to  break  down  a  programming  project 
to  identify  the  data  elements,  functions  and  procedures  that 
should  be  utilized  for  the  project.   The  rule  base  for  the 
Application  Developers  DSS  is  based  on  the  structure  and 
information  available  within  the  manpower  and  pay  database. 
The  initial  determination  that  a  user  will  have  to  make  is 
whether  the  primary  area  of  concern  is  within  the  manpower 
or  pay  area,  or  both.   The  possibility  that  a  transaction 
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will  effect  both  areas  must  be  considered  since  there  is  a 
large  area  of  overlap  between  the  two  functional  areas. 
Once  this  determination  has  been  made,  the  specifics  of  the 
application  are  addressed.   During  the  development  of  the 
Real  FAMMIS  Reporting  and  Retrieval  System  (R3S) ,  sixteen 
basic  categories  were  identified  as  valid  transaction 
categories.   These  sixteen  categories  are: 

Join 

Drop 

To 

From 

Training 

Dependents  Information 

Pay  (Debits/Credits) 

Discipline 

Performance 

Service  Information 

Contract  Information 

Personal  Information 

Basic  Individual  Record  Audit 

Unit  Information  (Events) 

Checklist  for  Personnel  Reportable  Items 

Checklist  for  Pay  Related  Reportable  Items  (Planning 
Analysis  Corporation,  1988) 


57 


Each  of  these  sixteen  categories  leads  to  more  detailed 
information  that  eventually  identify  disbursing  Type 
Transaction  Codes  (TTC)  that  can  be  associated  with 
individual  data  elements,  functions,  and  procedures. 

B.   DIALOG  COMPONENT 

The  Dialog  Component  of  the  DSS  will  represent  the  whole 
DSS  to  the  user.   It  will  be  the  only  part  of  the 
Application  Developers  DSS  that  the  user  actually  sees, 
therefore  it  is  crucial  that  the  User/System  dialog  operate 
smoothly  and  efficiently. 

The  primary  purpose  of  the  Dialog  Component  is  to  gather 
information  from  the  user  that  the  system  can  use  to  search 
through  the  Model  Base.   The  information  will  be  gathered 
through  an  interactive  User/System  dialog  that  presents  a 
user  with  a  series  of  questions  to  respond  to.   The 
questions  that  the  system  poses  to  the  user  come  from  the 
rule  base  that  is  designed  into  the  system.   Since  the  goal 
of  the  Application  Developers  DSS  is  to  provide  a  developer 
with  a  set  of  possible  data  elements,  functions  and 
procedures  for  use  in  a  program,  the  system  must  use  forward 
chaining  to  progress  through  the  rule  base. 

A  forward  chaining  inference  mechanism  is  often 
difficult  to  initiate  and,  as  noted  earlier,  often  appears 
quirky  to  the  user.   Despite  this,  it  is  the  only  method  to 
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achieve  the  desired  results.   Since  the  decisions  that  the 
system  must  handle  are  straight  forward  questions  with  clear 
cut  answers  some  of  the  awkwardness  will  be  removed  from  the 
system.   The  ability  to  limit  the  system  to  clear  cut 
questions  and  answers  removes  the  necessity  of  identifying 
confidence  factors  for  the  rules.   This  makes  the  system 
much  easier  to  program.   Rather  than  looking  for  the  most 
relevant  of  many  possible  rules  to  utilize,  the  system  can 
be  lead  directly  to  the  next  rule.   Since  the  Application 
Developers  DSS  has  many  different  branches  that  can  be 
traversed,  the  sequence  of  events  is  best  handled  by  a  case 
structure.   At  each  level  of  decision  the  system  should 
present  a  list  of  relevant  events  for  a  user  to  choose  from. 
Each  choice  will  lead  to  another  subset  until  the  ability  to 
divide  the  event  is  exhausted  and  the  system  arrives  at  a 
recommended  list  of  TTC's. 

The  Dialog  Component  will  also  have  the  ability  to  draw 
upon  the  capabilities  of  the  CFESA  to  further  enhance  its 
interaction  with  a  user.   The  event  choices  available  to  any 
developer  can  be  further  refined  based  upon  that  users  level 
of  access  contained  within  the  CFESA' s  security 
authorization  mechanism.   This  will  prevent  a  user  with  Read 
Only  authority  from  developing  an  application  that  would 
allow  him/her  to  make  changes  to  the  database  by  denying 
him/her  access  to  the  functions  and  procedures  that  allow 
those  changes  to  be  made. 

59 


C.   MODEL  BASE 

The  Model  Base  for  the  Application  Developers  DSS  is 
composed  of  the  data  elements,  functions  and  procedures  that 
relate  to  the  manpower  and  pay  functional  areas.   Most  of 
the  work  necessary  to  accumulate  this  model  base  has  already 
been  done,  in  one  form  or  another. 

1.   Data  Elements 

The  Manpower  and  Pay  Functional  Managers  modeling 
teams  have  expended  much  time  and  effort  in  designing  the 
Real  FAMMIS  database.   Through  the  use  of  Computer  Aided 
Systems  Engineering  (CASE)  technology  a  database  containing 
857  entities  and  1124  associations  has  been  identified.   The 
data  dictionary  for  this  database  should  comprise  the  data 
element  portion  of  the  Application  Developers  DSS  model 
base. 
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2 .   Functions  and  Procedures 

Much  of  the  work  compiling  functions  and 
procedures  that  are  applicable  to  certain  events  has  already 
been  accomplished  by  programmers  throughout  the  MCCDPA 
Kansas  City.   Most  programmers  are  in  the  habit  of 
developing  and  maintaining  libraries  of  these  types  of 
routines.   Use  of  these  libraries  saves  programmers  time  and 
machine  time  since  they  are  already  coded  and  debugged.   The 
only  difficulty  in  obtaining  these  routines  is  getting  the 
organizations  programmers  to  submit  them  for  inclusion  in 
the  model  base. 

The  biggest  concern  within  the  model  base  is  developing 
a  method  to  identify  which  functions  and  procedures  are 
applicable  to  which  events/data  elements.   One  method  of 
identification  would  be  through  the  use  of  the  TTC's  that 
are  already  linked  to  the  data  elements.   Utilizing  this 
method  would  provide  the  easiest  method  of  association  and 
would  only  require  limited  expansion  or  creation  of  TTC's  to 
identify  higher  level  events.   Adding  these  codes  to  the 
headers  of  each  function  and  procedure  would  allow  easy 
identification  of  applicable  items  based  on  the  results  of 
the  user/system  dialog. 
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Another  important  ability  that  the  model  base  must 
possess  is  the  ability  to  grow  and  adapt  to  changes.   If  the 
model  base  is  to  stay  relevant,  this  ability  must  exist.   A 
key  consideration  to  an  organization  is  where  the  authority 
to  make  changes  to  the  model  base  should  lie.   In  order  to 
effectively  address  this  problem,  the  position  of  Model  Base 
Administrator  (MBA)  should  be  created.   The  MBA's  duties  and 
responsibilities  would  parallel  the  duties  and 
responsibilities  of  a  Data  Base  Administrator  as  found  in 
many  organizations.   The  MBA  should  be  in  a  position  to  work 
closely  with  the  organization's  DBA  and  possess  an  intimate 
knowledge  of  the  functional  areas  requirements  and  purposes 
so  that  he/she  can  insure  that  the  model  base  stays  current. 
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VIII.   CONCLUSIONS  AND  RECOMMENDATIONS 


A.   CONCLUSIONS 
1.   General 

The  development  of  the  Application  Developers  DSS 
provides  the  MCCDPA  Kansas  City,  Mo.  with  the  opportunity  to 
increase  programmer  productivity  and  to  gain  additional 
benefits  from  work  that  has  previously  been  accomplished  by 
the  Real  FAMMIS  program  office.   It  will  build  on  work  that 
went  into  the  Event  Reporting  for  the  R3S  system  and  utilize 
the  basic  design  work  of  the  Real  FAMMIS  project  as  well  as 
utilize  the  capabilities  of  the  CFESA.   Since  the 
Application  Developers  DSS  will  be  make  use  of  a  new 
architecture  at  the  MCCDPA  it  is  difficult  to  assess  the 
viability  and  benefits  such  a  system  could  provide.   Based 
on  the  results  obtained  at  the  DOE  INEL  and  the  potential  to 
realize  a  significant  time  savings  in  the  early  stages  of 
program  development,  the  Application  Developers  DSS  gives 
every  indication  of  being  a  system  that  could  provide 
enormous  benefits  through  increased  programmer  productivity 
to  the  MCCDPA. 
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Without  the  CFESA,  development  of  the  Application 
Developers  DSS  would  be  much  more  difficult.   Extensive  work 
would  be  required  on  the  interfaces  between  the  data,  dialog 
and  model  base  components.   Working  within  the  CFESA  though 
relieves  the  interface  burden  from  the  DSS  developer  and 
allows  him/her  to  concentrate  upon  the  task  of  defining  the 
rules  and  establishing  the  model  base. 

2.  Inference  Mechanism 

The  inference  mechanism  driving  the  Application 
Developers  DSS  will  appear  as  a  menu  system  displayed  by  the 
system  that  allows  a  user  to  select  the  next  level  choice 
from  a  list  provided  to  him/her.   Beginning  the  inference 
mechanism  in  this  manner  will  allow  development  to  take 
place  incrementally  on  the  system  and  for  more  time  to  be 
spent  on  the  tool  box  contents  than  on  the  access  method. 
Once  the  tool  box  contents  have  been  finalized  and  initial 
feedback  has  been  achieved,  a  more  elaborate  processing 
scheme  for  the  inference  mechanism  can  be  developed  and 
installed  for  the  Application  Developers  DSS. 

3.  Model  Base  Components 

The  real  effectiveness  of  the  system  lies  in  the 
contents  of  the  CFESA  tool  box.   In  order  for  the  system  to 
be  utilized  the  developers  who  are  going  to  be  accessing  it 
must  believe  in  the  integrity  of  the  data  elements, 
functions  and  procedures  it  contains.   Initial  loading  of 
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the  tool  box  contents  should  receive  a  high  priority  during 
the  system  development.   Utilizing  the  information  developed 
during  the  Real  FAMMIS  information  engineering  effort  and 
further  incorporating  the  results  obtained  from  Information 
Engineering  Systems  Corporation's  User:  Expert  System 
software  package,  should  provide  the  initial  confidence  in 
the  data  element  components  within  the  tool  box.   The  same 
level  of  confidence  in  the  functions  and  procedures  can  be 
obtained  by  carefully  reviewing  each  one  submitted  for 
inclusion  and  thoroughly  testing  and  documenting  each  one 
before  it  is  added  to  the  tool  box. 

Continued  confidence  in  the  integrity  and  value  of  the 
items  in  the  tool  box  can  only  come  from  a  demonstrated 
commitment  to  keeping  the  items  up  to  date  and  accurate. 
This  can  be  accomplished  by  establishing  a  Model  Base 
Administrators  (MBA)  position  at  a  level  of  authority  equal 
in  degree  to  that  of  the  Data  Base  Administrator  (DBA) .   The 
duties  of  the  MBA  would  be  similar  to  those  of  the  DBA  in 
that  he/she  would  be  responsible  for  insuring  the  integrity 
of  the  items  in  the  tool  box  and  be  the  central  point  for 
changes  that  would  be  included  in  them. 


65 


B.   RECOMMENDATIONS 

The  Application  Developers  DSS  represents  an  opportunity 
for  the  MCCDPA  Kansas  City,  Mo.  to  realize  additional 
benefits  from  previously  accomplished  work  and  advance  into 
new  areas  of  program  development.   As  such,  the  following 
recommendations  are  provided: 

•  Determine  to  begin  incremental  development  of  the 
Application  Developers  DSS  after  the  installation  of  the 
CFESA  is  complete  at  the  MCCDPA  Kansas  City,  Mo 

•  Begin  collection,  identification  and  documentation  of 
standardized  functions  and  procedures  for  inclusion  in 
the  tool  box 

•  Create  the  position  of  Model  Base  Administrator  and 
staff  it  at  the  appropriate  level 

•  Expand  upon  the  TTC  identification  scheme  and  utilize  it 
to  identify  the  data  elements,  functions  and  procedures 
contained  in  the  tool  box 

•  General  and  Detail  Design  efforts  for  the  Application 
Developers  DSS  should  begin  as  soon  as  possible 
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Appendix  A 


Spider  Diagrams 


A-l 


The  diagrams  contained  on  the  following  pages  contain 
the  event  sequences  for  the  JOIN  event  leg  of  the  menu's. 
These  diagrams  correspond  with  the  diagrams  contained  in 
Appendix  B  as  noted  below  each  diagram. 


Level  0  Select  Event 


See   Appendix   B,    Page   B-3. 


A-2 


See   Appendix    B,    Page   B-4    to   B-7. 


A-3 


See  Appendix  B,  Page  B-6. 


A-4 


See  Appendix  B,  Page  B-6. 


A-5 


See   Appendix    B,    Page    B-6. 


A-6 


See  Appendix  B,  Page  B-6. 


A-7 


See  Appendix   B,    Page   B-6. 


A-8 


See  Appendix  B,  Page  B-4 . 


A-9 


See  Appendix  B,  Page  B-4 . 


A-10 


See  Appendix  B,  Page  B-4. 


A-ll 


See  Appendix  B,  Page  B-5  and  B-7 . 


A-12 


See  Appendix  B,  Page  B-5. 


A-13 


See  Appendix  B,  Page  B-6. 


A-14 


See  Appendix  B,  Page  B-4 . 


A-15 


See  Appendix  B,  Page  B-4 . 
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See  Appendix  B,  Page  B-4. 
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See  Appendix  B,  Page  B-7. 
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See  Appendix  B,  Page  B-7 . 
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See  Appendix  B,  Page  B-7. 
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See  Appendix  B,  Page  B-7. 
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See  Appendix  B,  Page  B-7. 
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Level  3  join  Event 

See  Appendix  B,  Page  B-7. 
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Level  3  Join  Event 


See  Appendix  B,  Page  B-7. 


A-24 


Level  3  Join  Event 


See  Appendix  B,  Page  B-7 . 
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See  Appendix  B,  Page  B-7 . 
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See  Appendix  B,  Page  B-5. 
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See  Appendix  B,  Page  B-5. 
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See  Appendix  B,  Page  B-5. 
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See  Appendix  B,  Page  B-5 
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See  Appendix  B,  Page  B-5. 
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See  Appendix  B,  Page  B-5. 
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See  Appendix  B,  Page  B-4 . 
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Appendix  B 


Screen  Maps 
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The  diagrams  contained  in  this  appendix  are  taken  from 
the  REAL  FAMMIS  Event  Reporting  document  prepared  by 
Planning  Analysis  Corporation.   They  are  included  here  for 
ready  reference  and  correlation  with  Appendix  A. 
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